Designers Corner with Prof. Mike Smith  Part 1  Part 2

Freezing a design and feature creep

About three weeks into designing the prototype (counting the first point we started work on the schematic as the beginning of design) we decided to freeze our design. At the last moment, we debated the idea of adding a USB connection or other debugging methods, but decided against it. Many times before (and it was to happen again) I have discovered that mistakes get made when you add features at the last minute (feature creep).

We “played it safe” by adding lots of standard 0.1-inch square header pins around the FPGA wired to the majority of the FPGA I/O pins. These header pins would allow us to make jumper connections if needed (and we did need and use these). Both Hamish and I have learned from experience the tremendous power that programmable logic gives you in being able to make a few external changes along with internal logic changes in a CPLD or FPGA. This ability to make logic and design changes rapidly proved very useful in our system.

We used a “play area”, a 3- by 4-inch area of a breadboard-like array of 0.1-inch spaced through-holes, which we could use to add any other chips and devices we might need (either to fix bugs or add functions). Such extra prototyping areas seem like a good idea, but in practice they rarely seem to get used. The addition of header pins around the FPGA is much more useful.

We socketed the FPGA (largely because we wished to be able to change between a variety of FPGA parts with the same footprint in the Xilinx Virtex family). We did not worry too much about cost of the board at this point. The zero insertion force sockets for large (we were using a 240-pin quad flatpack package) chips are expensive (several hundred dollars each), but there happened to be a few of these sockets left over from a previous project.

We decided not to socket the CPLD, RAM, or PHY chips. Several times when we were debugging our system we suspected a problem was due to a failure, defect, or other problem with one of these chips. Often we would swap out the FPGA just to see if that was causing a problem. Many times we were caught wishing that we had socketed all the chips. However, my experience in debugging prototype boards that use production (not preproduction) chips is that chips are almost never the cause of problems. Well over 95% of the time it is a design failure, not a chip failure.

Table of Contents   Previous   Next